Skip to content

태그: Service Mesh

총 11개의 글이 있습니다.

Control Plane Control plane은 Kubernetes의 전용 네임스페이스 (linkerd)에서 Linkerd 전체 제어를 위해 실행되는 서비스 집합이다. Destination Service 프록시가 서비스 디스커버리 정보를 가져오는 역할 서비스가 어디에 있는지, 어떤 TLS 인증서가 필요한지 등의 정보를 gRPC API로 제공 정책 정보와 service profile(재시도, 타임아웃, per-route metrics에 사용)을 프록시에 전달 Identity Service mTLS를 위한 인증서 발급 기능을 수행 프록시가 부트스트랩 시 CSR(Certificate Signing Request)을 보내면, CA 역할을 하여 서명된 인증서를 반환 프록시 간 통신에 필요한 TLS 신

A dry run (or practice run) is a software testing process used to make sure that a system works correctly and will not result in severe failure. Istio has a experimental annotation istio.io/dry-run to dry-run the policy without actually enforcing it. The dry-run annotation allows you to better understand the effect of an authorization policy before applying it to the production traffic. This helps

Terminal windowistioctl proxy-statusNAME CLUSTER CDS LDS EDS RDS ECDS ISTIOD VERSIONargocd-application-controller-0.argocd Kubernetes SYNCED SYNCED SYNCED SYNCED NOT SENT istiod-977466b69-2kms7 1.18.2argocd-applicationset-contr

Istio Arcitecture

An Istio service mesh is logically split into a data plane and a control plane. The data plane is composed of a set of intelligent proxies (Envoy) deployed as sidecars. These proxies mediate and control all network communication between microservices. They also collect and report telemetry on all mesh traffic. The control plane manages and configures the proxies to route traffic. The followi

Istio Configuration Profiles

default: enables components according to the default settings of the IstioOperator API. This profile is recommended for production deployments and for primary clusters in a multicluster mesh. You can display the default settings by running the istioctl profile dump command. demo: configuration designed to showcase Istio functionality with modest resource requirements. It is suitable to run the

Istio RBAC를 통해 네임스페이스, 서비스, HTTP 메소드 수준의 권한 제어를 실습 해보자. 준비작업 k8s, helm 설치 Istio 초기화 (namespace, CRDs) Terminal window$ wget tar -vxzf istio-1.8.2-osx.tar.gz$ cd istio-1.8.2$ kubectl create namespace istio-system$ helm template install/kubernetes/helm/istio-init --name istio-init --namespace istio-system | kubectl appl

Istio authorization

Istio는 ClusterRbacConfig를 통해 ServiceRole에 권한 Rule을 정의한 후 ServiceRoleBinding을 통해 특정 대상에 해당 ServiceRole에 지정하여 접근 제어를 수행한다. mesh, namespace, workload 범위에서의 access control을 적용할 수 있다. Istio authorization을 사용했을 때 얻을 수 있는 이점은 아래와 같다. 간단한 API: AuthorizationPolicy CRD를 통해 쉬운 접근 제어가 가능하다. 유연한 설정: CUSTOM, DENY 및 ALLOW 등 Istio 특성에 대한 사용자 지정 조건을 자유롭게 정의할 수 있다. 고성능: Envoy native를 사용하기에 성능이 우수하다. 높은 호환성: gRPC,

Resource Annotations & Labels

The various resource annotations that Istio supports to control its behavior.

Since not all services live in the sevice mesh, we need a way for services inside the mesh to communicate with those outdise the mesh. Those could be existing HTTP services or, more likely, infrastructure services like databases or caches. We can still implement sophisticated routing for services that reside outside Istio, but first we have to introduce the concept of a ServiceEntry. Istio builds

gateway log debug 하는 법

Debugging Istio Envoy filters can be challenging but there are several techniques and tools that can help you troubleshoot issues. Here’s a step-by-step guide to debug Istio Envoy filters: 1. Enable Debug Logs: By default, Istio’s Envoy sidecar logs only contain essential information. To get more detailed logs, you can enable debug logging by changing the log level. To do this, you’ll need to modi